In many circumstances it is desired to restrict access to various objects, such as files, within a computer system. In the simplest example of access control, only certain persons are permitted to read the contents of a sensitive file. In a more general statement, "objects" may also include resources, such as peripheral devices, external devices controlled by the computer system (e.g., weapons, devices controlling physical access to secured locations, and the like), as well as files or groups of files, such as directories. Further, there are varying levels of "access"; for example, in many cases, it is desired that certain individuals may only read a file, but may not alter or delete it, while others have more general "permissions" with respect to that file.
The issue of access control to objects within a computer system also arises in systems of significantly varying configuration, and operated according to widely differing mechanisms. For example, local area networks typically comprise a number of individual processor devices, i.e. personal computers or "PCs", linked such that all share certain resources, such as a file server. Such networks are commonly operated under control of an "operating system", which may include the capability to provide varying individuals with varying "permissions" with respect to objects stored on the file server. For example, Microsoft Corporation's "Windows NT" operating system provides this capability, by associating an "access control list" ("ACL") (this being an example of an "access control specification", as the latter term is used in the art) with each "object", e.g., with each controlled file or group of files, i.e., with a directory of controlled files. Windows NT allows various permissions to be associated by the ACL with individuals or groups of individuals, so that the access sought is permitted only if the user's identification matches the a user entry in the ACL or the user is a member of a group entry in the ACL, and the user or group entry is associated with permissions for the access sought.
The issue of access control also arises in connection with relational databases, which may be accessed from a variety of processors not necessarily connected in a network operated by a single operating system per se; access control lists are then typically associated with portions of the database and operated similarly.
The question of access control also arises in connection with objects stored such that they can be accessed over the "Internet" or "Web", i.e., such that they can be located by universal resource locator ("URL") inquiries; the "servers" storing the resources sought may similarly store ACLs for restricting access to various objects to individuals or groups of individuals.
Stated more generally, therefore, access control mechanisms, e.g., as effectively defined by an operating system such as Windows NT, require that security attributes be maintained concerning both users and objects. User security attributes may consist of defined groups ("roles") to which the user belongs, wherein access to various objects is permitted to all of the individuals identified as members of the group; this technique, which simplifies the assignment of permissions to users with respect to various objects by assigning various individuals to groups according to their status, is commonly referred to as "Role-Based Access Control" ("RBAC"); see co-pending Ser. No. 08/980,908, of one of the present inventors, incorporated herein by this reference.
Object security attributes generally consist of the permissions required to perform operations on the object. Access control mechanisms provided by the computer system--again, which terminology includes relational databases and the Web as well as local area networks and the like--compare user security attributes and object security attributes in order to determine access.
In each of the typical types of computer systems discussed above, object security attributes are usually kept with the object (e.g., in the header of a file) and the object resides in (or a resource is accessed through) a single server. Consequently, when an object is accessed, its security attributes can be conveniently evaluated once the object has been located. Furthermore, changes in object security attributes--e.g., to add or subtract an individual from those having access of a specified type to a particular object--need only be made at a single location.
Administering users' access to resources is often accomplished by directly associating users with permissions, that is, by providing an ACL with respect to each object or, at best, groups of objects already organized in some known way, i.e., as files within a directory. This approach can be particularly difficult, error-prone, and costly to administer when users enter and leave an organization and when users' responsibilities change within an organization, because each ACL must then be correctly altered. Comparable difficulties arise in connection with changes involving the control of access to a relational database, wherein the resources are equivalent to tables, and the access control information amounts to a list of operations that each individual (or role member) may perform.
As noted above, user access control mechanisms have been designed to address these problems and simplify the process of effectuating changes in the status of individuals and objects by the use of "roles", whereby individuals may be organized conveniently into groups, such that each member of a particular groups is accorded the same set of permissions with respect to a group of associated objects. In effect, such Role Based Access Control (RBAC) mechanisms provide a mechanism whereby individuals may be assigned to groups; the group is then listed on an Access Control List (ACL) associated with an object or group of objects.
The central notion of Role-Based Access Control (RBAC) is that users do not have discretionary access to enterprise objects. Instead, access permissions are administratively associated with roles, and users are administratively made members of appropriate roles. This idea greatly simplifies management of authorization while providing an opportunity for great flexibility in specifying and enforcing enterprise-specific protection policies. Users can be made members of roles as determined by their responsibilities and qualifications and can be easily reassigned from one role to another without modifying the underlying access structure. Roles can be granted new permissions as new applications and actions are incorporated, and permissions can be revoked from roles as needed. Furthermore, most RBAC mechanisms support the idea of heirarchical groups, i.e., where a member of "manager", for example, automatically obtains all permissions provided to "subordinate".
By comparison, the basic idea of conventional ACLs is to associate an object (or group of objects, such as a "directory" of "files", in Windows parlance) with a list of users and groups. Associated with each user or group in an ACL for an object is a set of operations which may be performed on that object. An operation on the object may be performed by a user if that user or a group to which that user belongs is listed in the ACL associated with the object and that operation is associated with that user or group. Windows NT is one well-known operating system which supports such ACL mechanisms. However, while as noted Windows NT does allow assignment of groups to ACLs, heirarchical permissions are not supported. "PASC P1003.le" is an IEEE specification for an operating system interface which similarly supports ACLs.
Adding implementation of RBAC provides several advantages over simply controlling access to objects by ACLs. Even a very simple RBAC model affords an administrator the opportunity to express an access control policy in terms of the way that the organization is viewed, i.e., in terms of the roles that individuals play within the organization. With RBAC, it is not necessary to translate a natural organizational view into another view in order to accommodate an access control mechanism. In addition, most RBAC models have features which most ACLs do not. In particular, as noted above, many RBAC models support role hierarchical organization of roles, where one role can "inherit" the permissions accorded another.
Thus, by associating permissions with roles or groups and by moving users in and out these roles or groups, the complexity of permission assignment administration can be reduced, lowering the total cost of security administration and improving its reliability. Thus, RBAC simplifies the problem of maintaining user access control.
There is, however, no comparable mechanism for simplifying object access control. In the prior art, object access control is handled resource by resource; more specifically, in NT and other operating systems, an access control list is not itself treated as an independent entity that might be associated with a file or group of files, but is simply an attribute of the file's definition. Accordingly, changes must be made resource by resource. This can be a significant task for a system administrator, and, again, errors amount to breaches of the security system.
The basic architecture of the ACL mechanism is shown by U.S. Pat. Nos. 4,621,321 and 4,701,840 to Boebert, which also draw a distinction between ordinary and distinguished objects in a computer system.
Prior art patents further exemplifying such practices, and in some cases pointing out the difficulties and shortcomings thereof, include U.S. Pat. No. 5,720,033 to Deo, U.S. Pat. No. 5,265,221 to Miller, and U.S. Pat. No. 5,787,427 to Benantar, all showing assignment of a number of objects requiring common access control lists to groups.
Also generally pertinent to issue of access control in a computer system are U. S. Pat. No. 5,701,458 to Bsaibes; U.S. Pat. Nos. 5,802,276 and 5,765,153 to Benantar; U.S. Pat. No. 5,809,506 to Copeland; and U.S. Pat. No. 5,768,504 to Kells. U.S. Pat. No. 5,163,147 to Orita discusses the "level" concept of computer security (see U.S. Ser. No. 08/975,189, now U.S. Pat. No. 6,023,765 for disclosure of a method for incorporating RBAC into such a system). Finally, U.S. Pat. No. 5,202,997 to Arato relates to control of peripherals.
With the role or group approach to security administration, much of the effort in providing administrative tools has been devoted to tools, such as RBAC, for associating users with roles or groups. As noted above, although operating environments typically used in access control management applications, for example Windows NT, do not have a general mechanism for group hierarchies, the use of hierarchies in administering the relationships between users and roles or groups can significantly reduce administrative costs by allowing access control to be defined with respect to such roles or groups of individuals.
As noted above, there is at present no mechanism available for analogously assigning access control status to collections of objects, apart from the capability of assigning ACLs to directories. Hence significant difficulties arise in connection with access control to objects or groups of objects.